Some SQL databases may implement a concept of “roles” for dealing with privileges in a context of access control. A role typically bundles privileges, and may also include or inherit other roles. These roles may then be assigned to users, and a given user may consequently be able to act according to specific privileges specified by the roles assigned to that user. As databases and/or database management systems (DBMS) continue to evolve and implement more powerful programming and scripting capabilities, complications may arise in the specific implementations, resulting in added management overhead for implementers, developers, and/or administrators to consider and carry out, in order to avoid security vulnerabilities and/or mitigate risk and extent of potential data leaks, compromises, and/or other unauthorized access to access-restricted data stored in particular database(s).
Database scripting language(s) may be leveraged to implement program units, e.g., blocks, stored procedures (SP), etc., within a DBMS. These database program units may be subject to some authorization constraint(s). Some typical constraints may be for “definer” or “caller” in some examples. With definer or caller constraints, a given SP may be executed with roles of either the definer of the procedure or the caller of the procedure, respectively. Although this may suffice for some circumstances, implementation of such coarse constraints may also subtly introduce insidious security vulnerabilities into the DBMS.
For example, a block or SP may require some kind of “generic” access to a database, specifically at a part of the database that is not directly accessible by the caller of the unit. A conventional solution may be to define the SP with “definer” privileges, and to ensure that the definer of the SP then has sufficiently far-reaching privileges. More complicated examples may involve several SPs, each having different privilege requirements. Developers thus may often cluster all required privileges in just one role to be reused with multiple SPs. This may in turn let any such SP be executed with more privileges than it actually needs. As a result, this kind of design may increase the attack surface of a DBMS for SQL injection attacks, and may decrease confinement of SQL-injection security breaches, potentially exposing large amounts of sensitive data to unauthorized users or other unintended parties.
In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.